The present invention generally relates to a hop-count management method and to a node apparatus using this method.
In a node apparatus performing packet communications by using, for example, Internet Protocol (IP), control information for assigning specific labels to specific packet streams can be exchanged between nodes. Each node then, stores input labels (and input interfaces) and output labels (and output interfaces) assigned to the individual streams, and performs a packet transfer operation (switching operation) in accordance with the relationship between the stored input and output labels. This scheme is referred to as a xe2x80x9clabel switching techniquexe2x80x9d.
Generally, the lengths of the labels are fixed, and faster processing is achieved and more flexible path control is enabled by employing the above-described label switching packet transfer operation than by utilizing a conventional packet transfer operation performed by analyzing packet header information (destination IP address prefix, etc.).
The path through which packet streams are label-switched is referred to as a xe2x80x9clabel switched path (LSP)xe2x80x9d. A node, which is located at the ingress of the LSP for transferring a packet stream, is referred to as an xe2x80x9cingress nodexe2x80x9d, and performs packet transfer after analyzing an IP packet which belongs to the packet stream and attaching a label to the packet. A node, which is located at the egress of the LSP for transferring the packet stream, is referred to as an xe2x80x9cegress nodexe2x80x9d, and performs packet transfer after removing the label from the received packet. A node, which is placed between the ingress node and the egress node in the LSP so as to connect these nodes, is referred to as an xe2x80x9cintermediate nodexe2x80x9d, and performs packet transfer in accordance with the relationship between the input and output labels.
A stream to be transferred in a certain LSP may be various packets, such as a packet provided with a specific destination IP address, a packet provided with a specific destination IP address prefix (network address), and a packet passing through a specific egress node belonging to a certain domain.
LSPs may include at least point-to-point LSPs for unicast streams (one ingress node and one egress node are provided), and point-to-multipoint LSPs (one ingress node and a plurality of egress nodes are provided, and the LSP is branched off at an intermediate node into at least two portions) for multicast streams. Additionally, multipoint-to-point LSPs (a plurality of ingress nodes and a single egress node are provided) may be defined if a stream merge function of relating a plurality of input labels to a single output label is provided in an intermediate node.
To specifically implement the above-described label switching, a header defined in the known datalink switching technique, such as an asynchronous transfer mode (ATM) and a frame relay, may be used. Alternatively, a label header newly defined specifically for label switching may be used.
In the second technique, a label header field (hereinafter referred to as a xe2x80x9cgeneric label headerxe2x80x9d) is inserted between a point-to-point protocol link (PPP link) frame header and an IP header or between a logical link control (LLC) header of a local area network (LAN) and an IP header, and a label value filled in the generic label header field is used as switching information.
In the generic label header, not only a label field used as the switching information, but also a Time-To-Live (TTL) field for checking the number of nodes through which a packet passes (hereinafter sometimes referred to as a xe2x80x9chop-countxe2x80x9d) and a Class of Service (CoS) field for indicating the priority of performing transfer operation are defined. The TTL field and the CoS field are also defined in a conventional IP packet header. If each node (not only the ingress node and the egress node, but also an intermediate node) decrements the TTL value in the generic label header one-by-one upon transferring a packet by label switching, it is possible to discard the packet which have passed through a number of nodes greater than a predetermined number of nodes due to a reason, such as circling in the transfer path (routing loop).
In contrast, if the aforementioned first technique, i.e., a known datalink switching technique, is used for implementing label switching, a Virtual Path Identifier/Virtual Channel Identifier (VPI/VCI) field of an ATM cell header or a Data Link Circuit Identifier (DLCI) field of a frame relay header may be used as a label field.
In this case, a standardized ATM cell header format or frame relay header format is used, but the TTL field and the CoS field discussed previously are not defined for these header formats. Accordingly, once a packet (cell) is input into an LSP formed by the ATM virtual connection (VC), it may not be discarded and circles indefinitely in the LSP due to, for example, routing loop.
As one of the measures to overcome the above-described drawback, the following method has been proposed. By using a Label Distribution Protocol (LDP) for establishing, maintaining, and releasing an LSP, the number of nodes through which a packet passes (the hop-count) in each LSP from an ingress node to an egress node is stored in the ingress node or in the egress node. Then, when a packet is actually transferred, the TTL value of the IP packet header is decremented by the hop-count stored in the ingress node or the egress node.
In this method, the ingress node transmits a xe2x80x9clabel request messagexe2x80x9d for requesting an assignment of a label to a specific packet stream defined by, for example, a destination network prefix. Then the downstream node receives the label request message and further transmits it to its neighboring node toward the egress node. In this manner, the label request message is forwarded to the egress node, and the egress node sends back a xe2x80x9clabel mapping messagexe2x80x9d for assigning the label to the specific packet stream. Alternatively, the egress node may voluntarily transmit a label mapping message to the upstream node, even if it does not receive any label request message. Then the upstream node receives the label mapping message and further transmits it to its neighboring node toward the ingress node.
The label mapping message transmitted from the egress node includes not only the label value to be informed to the upstream node""s, but also the hop-count representing a value of one. When a node receives the label mapping message from its neighboring downstream node, the node transmits the label mapping message to its neighboring upstream node after incrementing the hop-count value by one. Ultimately, the ingress node that has transmitted the label request message receives the label mapping message and stores the hop-count value indicated in the label mapping message, which represents the number of nodes between the ingress node and the egress node.
Then, when the ingress node receives a packet belonging to a packet stream corresponding to the above-described label, it decrements the TTL value of the packet header by the stored hop-count value and checks whether the decremented TTL value has reached zero before transmitting the packet. If the TTL value has reached zero, the packet may be discarded at the ingress node.
The aforementioned method, where the number of hops in the LSP from the ingress node to the egress node is informed to the ingress node by the label mapping messages and the ingress node decrements the TTL value of a packet to be transmitted through the LSP by the informed hop-count value, is effective only when all the intermediate nodes located on an LSP are unable to check and update the TTL value in a packet transferred. That is, it is effective only in a system where all the nodes forming the LSP use the same known datalink switching technique, such as ATM or frame relay.
Considering an actual label switching network, both ATM and frame relay may be employed, or both ATM and a Synchronous Optical Network (SONET)-based point-to-point link may be used, in a single network. However, the control mechanism previously discussed above has been proposed, assuming that one of ATM and frame relay is solely used in the label switching network and that all the intermediate nodes located on an LSP are unable to perform TTL processing.
Consequently, the proposed control mechanism cannot deal with a case where two or more different types of network segments are provided in one LSP, especially where one type of the network segments includes an intermediate node which is able to check and update the TTL field of the generic label header and another type of the network segments includes an intermediate node which is unable to perform TTL processing.
It is therefore an object of the present invention to provide a hop-count management mechanism for enabling each node of the LSP, that transfers a packet by using the label switching technique to appropriately decrement the TTL value, especially in a case where one LSP is established through both a node that can process a TTL value of an IP header or a generic label header and a node that cannot process the TTL value, so that an adequate TTL value, which realizes an interoperablity with a conventional hop-by-hop transfer technique, can be provided in the IP header of the packet output from the egress node of the LSP.
According to one aspect of the present invention, there is provided a method of managing a hop-count value of a label switched path (LSP) which is configured by nodes that perform a label switching operation on an input packet by referring to a correlation between input labels and output labels assigned to a packet stream corresponding to the input packet. In this method, a node, which has received from one of an upstream node and a downstream node a message (for example, the label request message or the label mapping message) including a hop-count of the LSP, determines whether or not the node itself is going to update, upon performing the label switching operation on a packet received, information (for example, the TTL value) included in the packet concerning the number of nodes through which the packet passes.
If the node determines that the information is not to be updated in this node, the node increments the hop-count in the received message by a prescribed value (for example, by one), and then transfers the message to other of the upstream node and the downstream node. This message including the hop-count is preferably received from the downstream node and transferred to the upstream node in a case of establishing a unicast or stream-merge LSP, and is preferably received from the upstream node and transferred to the downstream node in a case of establishing a multicast LSP. If the node determines that the information is to be updated in this node, the node transmits a message indicating that the node itself is going to update the information (for example, a message including a value of one as the hop-count or a message not including the hop-count) to the other of the upstream node and the downstream node.
When the node that determines to update the information by itself receives a packet through the LSP, the node updates the information in the received packet based on the hop-count which has been reported from the one of the upstream node and the downstream node and is stored in the node (for example, the node decrements the TTL value in the packet by a value of the hop-count). In other words, if the one of the upstream node and the downstream node does not have a function of updating the information, the node is supposed to have received the message including the hop-count incremented (for example, two or greater), and thus the node updates the information based on this incremented hop-count.
If the one of the upstream node and the downstream node has a function of updating the information, the node updates the information in the received packet by a predetermined value (for example, decrements the TTL value by one). In practice, the predetermined value may also be stored in the node as the hop-count that is referred to upon updating the information.
According to the principle of the above-described present invention, the upstream node that processes the TTL value can decrement it in advance by the number of hops from that node to a downstream node some hops ahead that subsequently processes the TTL value, for example, in a unicast or stream-merge LSP passing through both a node that is able to process the TTL value of the generic label header and a node that is unable to process the TTL value. Alternatively, the downstream node that processes the TTL value can decrement it later by the number of hops from an upstream node some hops before that previously processes the TTL value to that node, for example, in a multicast LSP passing through the above different types of nodes. As a whole, an adequate TTL value of an IP header, which is equivalent to that will be obtained by a hop-by-hop transfer technique, can be provided for an IP packet output from the egress node of the LSP to a network operated by the hop-by-hop transfer technique.
In the aforementioned method, a node may determine that it is to update the information, when any one of the input label and the output label is set in the same header field (for example, the generic label header field) as the header field in which the information is contained.
A node may determine that it is not to update the information, when both the input label and the output label are set in a header field (for example, a layer-2 header field) different from a header field in which the information is contained. Alternatively, a node may determine that it is to update the information, when neither of the input label nor the output label is set in the same header field as the header field in which the information is contained, but when the type of input label and the type of output label are different (for example, an ATM header and a frame relay header).
According to another aspect of the present invention, there is provided a node apparatus for operating the above-described method.
According to yet another aspect of the present invention, there is provided a computer usable medium having computer readable program code means embodied therein for a computer functioning as the above node apparatus.
Other features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings.
Both the foregoing general description and the following detailed description provide examples consistent with this invention and explain how to make and use systems, methods, and articles of manufacture consistent with the invention. These descriptions do not restrict the claimed invention.